Skip to content

Add enum entries to InfoGreTun and InfoGreTun6 #174

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Toorero
Copy link
Contributor

@Toorero Toorero commented Aug 9, 2025

This pull request exposes the most common IFLA_GRE_* attributes by adding them to InfoGreTun and InfoGreTun6 respectively. On that matter I bundled the link::link_info::gre* modules into a new link::link_info::gre module. This was done so I can define used GRE structures shared by InfoGreTun and InfoGreTun6 like the IFLA_GRE_* constants.

@Toorero Toorero force-pushed the feature/info_gre_tun branch 2 times, most recently from 1a5eea1 to cf6e5dc Compare August 9, 2025 16:34
@Toorero

This comment was marked as outdated.

@Toorero Toorero force-pushed the feature/info_gre_tun branch 2 times, most recently from ae5aa3a to 3bd79ff Compare August 11, 2025 16:28
Ttl(u8),
EncapLimit(u8),
FlowLabel(u32),
Flags(u32), // TODO: expose IP6_TNL_F_* flags
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If todo, then remove it. Otherwise, we have to break the API when we change it bitflags.

Copy link
Contributor Author

@Toorero Toorero Aug 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently we break the API all the time by substituting generic Netlink attributes with concrete bindings like is done here. Deserializing will now yield the concrete enums instead of the generic Netlink attributes. Breaking API changes are required and currently okay, since we are on major version 0 where the public API can't be considered stable (yet).

I just haven't looked into what the flags are for in the Kernel yet and so I left them out.

I don't really get why we'd want to "remove" todos and why removing them would protect us from breaking the API in the long term if we'd still implement it eventually (since this is what a todos is, if present as a comment as a reminder or not). Additionally there are other places in the code where todos are present that would introduce breaking API changes.

@Toorero Toorero force-pushed the feature/info_gre_tun branch 3 times, most recently from 7630867 to a66c359 Compare August 20, 2025 07:00
@Toorero Toorero force-pushed the feature/info_gre_tun branch from a66c359 to 6dddc0c Compare August 20, 2025 07:00
@Toorero Toorero requested a review from cathay4t August 20, 2025 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants